Hello, I'm currently facing the problem to manage common libraries across addins/projects/attribs/layouts. The requirements in detail:
To fulfill these requirements, things are easy as long as we talk about the non-library parts, i.e. those parts can be handled by applying multiple parts to the registry entries or command line parameters. But: it seems to me that the libraries themselves cannot be placed in the required way, as the only path where DOORS is looking for code beside the addins, projects etc. is the DOORSHOME, and this is conflicting with requirement #4. And, the -H parameter obviously allows only one argument, not a list, like the other parameters. The only solution I see is to replicate the DOORSHOME/* structure to the project space, and to put the libraries in there, and to redirect the DOORSHOME path by the relating registry entry/command line parameter. Is this correct, or do you have any other idea? Best regards, Gerhard GerhardS - Thu Apr 03 04:47:37 EDT 2014 |
Re: Library concept? Hi, You have to be conform to the registry entries that DOORS works with:
See this page to understand how to use them: What I do is:
I also have the same structure locally and a .reg that points to my hard disk to make changes prior to send them to production. I use WinMerge to syng folders. You can have different versions of the reg file if you need to give access to different options to different people. Hope this helps... Alain
|
Re: Library concept? adevicq - Thu Apr 03 08:26:57 EDT 2014 Hi, You have to be conform to the registry entries that DOORS works with:
See this page to understand how to use them: What I do is:
I also have the same structure locally and a .reg that points to my hard disk to make changes prior to send them to production. I use WinMerge to syng folders. You can have different versions of the reg file if you need to give access to different options to different people. Hope this helps... Alain
Thanks, Alain, for your suggestion. Let me try to put more focus on the critical point: It is _not_ the problem to have multiple folders for addins etc.; but it is the problem to have common libraries across all these, being provided _outside_ the DOORSHOME. This is, what I suppose not to be possible, as DOORS first searches the DOORSHOME/bin, then the DOORSHOME/lib/dxl, then the addins etc. for #include code. If you now want to have a library, which shall provide code for addins, projects, etc., you either have to duplicate the code to everywhere, or you have to put it into the DOORSHOME, so change the DOORS installation (which is, for many customers, not allowed by their IT departments). The consequence seems to me to duplicate the whole DOORSHOME to a shared location, and put the library code in there. But this is also not too nice; so perhaps there is any other idea about that problem... Hope that clarifies my problem. - Gerhard |
Re: Library concept? GerhardS - Thu Apr 03 08:54:26 EDT 2014 Thanks, Alain, for your suggestion. Let me try to put more focus on the critical point: It is _not_ the problem to have multiple folders for addins etc.; but it is the problem to have common libraries across all these, being provided _outside_ the DOORSHOME. This is, what I suppose not to be possible, as DOORS first searches the DOORSHOME/bin, then the DOORSHOME/lib/dxl, then the addins etc. for #include code. If you now want to have a library, which shall provide code for addins, projects, etc., you either have to duplicate the code to everywhere, or you have to put it into the DOORSHOME, so change the DOORS installation (which is, for many customers, not allowed by their IT departments). The consequence seems to me to duplicate the whole DOORSHOME to a shared location, and put the library code in there. But this is also not too nice; so perhaps there is any other idea about that problem... Hope that clarifies my problem. - Gerhard Hi again, No, there is no problem to share libraries. You just have to add the right include path. For example, we use includes for Layout and Addins and we share the file. We never had to make copies of dxl files. My "addins" folder is organized in the following way:
Same for others
(to be honest, I could have avoided the "Cegedim" intermediate level to make it simpler...) in each dxl file (whatever its location) I add the includes like this: #include <include/Cegedim/myincfile.inc> DOORS finds the file in the "addins/include/Cegedim" folder. Does it answer your question? Alain
|
Re: Library concept? adevicq - Thu Apr 03 09:48:50 EDT 2014 Hi again, No, there is no problem to share libraries. You just have to add the right include path. For example, we use includes for Layout and Addins and we share the file. We never had to make copies of dxl files. My "addins" folder is organized in the following way:
Same for others
(to be honest, I could have avoided the "Cegedim" intermediate level to make it simpler...) in each dxl file (whatever its location) I add the includes like this: #include <include/Cegedim/myincfile.inc> DOORS finds the file in the "addins/include/Cegedim" folder. Does it answer your question? Alain
So it seems that even if the context is somewhere else (e.g. in project/...), DOORS finds files that are located in other contextes (e.g., in addins/...). However, there remains the question how to enhance the DOORSHOME (e.g., context menus) without duplicating that one as a whole, to be able to redirect the -home setting - any solution for that?
- Gerhard |
Re: Library concept? GerhardS - Thu Apr 03 11:01:56 EDT 2014 So it seems that even if the context is somewhere else (e.g. in project/...), DOORS finds files that are located in other contextes (e.g., in addins/...). However, there remains the question how to enhance the DOORSHOME (e.g., context menus) without duplicating that one as a whole, to be able to redirect the -home setting - any solution for that?
- Gerhard If what you call "context menus" corresponds to menus and menu items in the explorer or module windows, it works as DOORS gets the DXL for these menus from the addins and projectaddins registry entries. Therefore you can create as many menus / submenus as needed. If this is about menus tha open when right lcicking on an obect I don't know as I don't use this feature... Alain
|
Re: Library concept? The key here is that #include file references are resolved vis-a-vis the "addins" variable, which controlls the formal-module menus. I have a "DXL-v9" folder, that has these sub-folders; but does NOT have any "DXL-v9.hlp" nor "DXL-v9.idx"
The "addins" variable will look like this:
The DXL scripts include as follows:
-Louie Note that since the DXL-v9 folder does not have any hlp nor idx file, that folder is effectivly ignored when DOORS attempts to build the module menu. Now you could skip that reference and put the "Includes" folder under the "Menu-Formal" folder but I found CM was easier with the way stated above. |
Re: Library concept? adevicq - Thu Apr 03 11:16:13 EDT 2014 If what you call "context menus" corresponds to menus and menu items in the explorer or module windows, it works as DOORS gets the DXL for these menus from the addins and projectaddins registry entries. Therefore you can create as many menus / submenus as needed. If this is about menus tha open when right lcicking on an obect I don't know as I don't use this feature... Alain
Your understanding is right, Alain: I do _not_ mean the top-level menues (those at the upper window border), but the context menus that you get by right-clicking on something (so: lib/dxl/config/formalPopupMenu and similar ones). Sharing the code under addins/project/... _only_ is not my problem. My problem is to have code shared among _all_ of that stuff, this means: libraries, that those context menus can use as well as the tools under addins/project/... To give a simple example: Imagine an administrative module where the objects hold references to other modules. If there shall be an "addins" menu providing a function "open selected module", as well as a context menu providing the same function for a specific object, both functions shall obviously use the same library code which executes the "open module". So: While the "addins" call is located somewhere in the addin's .idx file, the context menu call is located in the DOORSHOME area, in the formalPopupMenu environment. When deploying that, this raises the need to modify the DOORSHOME area, what is a problem. It may be acceptable to have the call there, but not a bunge of other code; that code shall be in the "addins" environment. Currently (after a bunge of experiments) it seems to me that there is no way around duplicating the whole DOORSHOME stuff to somewhere else, put all the code in there, and redirect the path via the -H command line switch. |
Re: Library concept? GerhardS - Fri Apr 04 01:45:06 EDT 2014 Your understanding is right, Alain: I do _not_ mean the top-level menues (those at the upper window border), but the context menus that you get by right-clicking on something (so: lib/dxl/config/formalPopupMenu and similar ones). Sharing the code under addins/project/... _only_ is not my problem. My problem is to have code shared among _all_ of that stuff, this means: libraries, that those context menus can use as well as the tools under addins/project/... To give a simple example: Imagine an administrative module where the objects hold references to other modules. If there shall be an "addins" menu providing a function "open selected module", as well as a context menu providing the same function for a specific object, both functions shall obviously use the same library code which executes the "open module". So: While the "addins" call is located somewhere in the addin's .idx file, the context menu call is located in the DOORSHOME area, in the formalPopupMenu environment. When deploying that, this raises the need to modify the DOORSHOME area, what is a problem. It may be acceptable to have the call there, but not a bunge of other code; that code shall be in the "addins" environment. Currently (after a bunge of experiments) it seems to me that there is no way around duplicating the whole DOORSHOME stuff to somewhere else, put all the code in there, and redirect the path via the -H command line switch. Well, you can us the "#include" directive in any dxl file including those located in the "formalPopupFiles" folder. I never tried but I am sure that this works. Have you? |
Re: Library concept? adevicq - Fri Apr 04 03:07:28 EDT 2014 Well, you can us the "#include" directive in any dxl file including those located in the "formalPopupFiles" folder. I never tried but I am sure that this works. Have you? Sure; the problem is a bit less problematic, when you're using absolute paths in those #includes. However, this is not very nice, so I'd like to use relative paths there. This is part of where my questions are about... |
Re: Library concept? llandale - Thu Apr 03 14:22:57 EDT 2014 The key here is that #include file references are resolved vis-a-vis the "addins" variable, which controlls the formal-module menus. I have a "DXL-v9" folder, that has these sub-folders; but does NOT have any "DXL-v9.hlp" nor "DXL-v9.idx"
The "addins" variable will look like this:
The DXL scripts include as follows:
-Louie Note that since the DXL-v9 folder does not have any hlp nor idx file, that folder is effectivly ignored when DOORS attempts to build the module menu. Now you could skip that reference and put the "Includes" folder under the "Menu-Formal" folder but I found CM was easier with the way stated above. Thanks, Louie - but what about relative #include references from a DOORSHOME/lib/dxl/config/formalPopupMenus/something.dxl to a library.inc which shall also be used by the SOMEWHEREELSE/addins/PROJECT/somewhat.dxl? Where to locate the library.inc so that it will be found by both? - Gerhard |
Re: Library concept? GerhardS - Fri Apr 04 08:16:52 EDT 2014 Thanks, Louie - but what about relative #include references from a DOORSHOME/lib/dxl/config/formalPopupMenus/something.dxl to a library.inc which shall also be used by the SOMEWHEREELSE/addins/PROJECT/somewhat.dxl? Where to locate the library.inc so that it will be found by both? - Gerhard Once you get any DXL to "find" your library, all will find it. That is, the following behaves exactly the same regardless of the type of DXL (attr-DXL, Trigger, on-demand) or where it is located:
-Louie |
Re: Library concept? GerhardS - Fri Apr 04 08:16:52 EDT 2014 Thanks, Louie - but what about relative #include references from a DOORSHOME/lib/dxl/config/formalPopupMenus/something.dxl to a library.inc which shall also be used by the SOMEWHEREELSE/addins/PROJECT/somewhat.dxl? Where to locate the library.inc so that it will be found by both? - Gerhard ... and if you worry about the separation of Addins vs. a General Library all you need to do is have to entries in your ADDINS path: ADDINS = \\Somewhere\GeneralLibrary; \\SomewhereElse\Addins1; \\SomeWhereEvenDifferent\Addin2 and your Directory Structure would look like:
\\Somewhere\GeneralLibrary
\Library.inc
\\SomewhereElse\Addin1
\Main Menu 1
\\SomeWhereEvenDifferent\Addin2
\Main Menu 2
Since the general library is on the ADDINS Path all relative includes will find it. Of course if you reference the general library in formalPopupMenus then you might get the problem, that DOORS will not startup correctly if the General Library is not on the addins path. Maybe this clarifies it a bit more... Regards, Mathias |
Re: Library concept? llandale - Fri Apr 04 11:53:40 EDT 2014 Once you get any DXL to "find" your library, all will find it. That is, the following behaves exactly the same regardless of the type of DXL (attr-DXL, Trigger, on-demand) or where it is located:
-Louie Thanks, Louie, that was the information I needed. Actually, I already tried that, but for any reason it didn't work that way on my machine. I now had the chance to try that on a clean machine, and voilà, it worked fine. |